home *** CD-ROM | disk | FTP | other *** search
/ Acorn User: China / Acorn User China CD-ROM (UK) (Disc B) / Acorn User China CD-ROM (UK) (Disc B).bin / BARNET / ARMLINUX / MAIL / 9707 / text0034.txt < prev    next >
Encoding:
Text File  |  1997-11-30  |  3.9 KB  |  81 lines
  1. Charles Esson writes:
  2. > Would this only occure if the same physical address was mapped into
  3. > different virtual addresses with write enabled.      I see it as a
  4. > reasonable restiction that virtual be mapped to the real on a one to one
  5. > basis when write is enabled.
  6.  
  7. But the cache works on VIRTUAL ADDRESSES NOT PHYSICAL!  If the processor
  8. finds a cache entry for the virtual (program) address, then it *will*
  9. use it!  It doesn't care about the mapping.  The reason for this is that
  10. the processor/cache/mmu work as follows:
  11.  
  12.     Processor wants to read a word.
  13.      - cache gets searched (always, whether caching is enabled or not).
  14.         if entry is found, use it.
  15.      - if no entry is found, use the mmu to obtain data.  If caching
  16.         is enabled, insert this data into the cache.
  17.  
  18. The data sections have to use different physical pages for data for
  19. different tasks.  Let's say that two task fopen's a file.  FILE * is
  20. returned from an array of FILE *filp[].  filp would be located in the
  21. shared library.
  22.  
  23. > To use fixed address libaries code one could you put aside the fixed
  24. > addresses required for these libaries. The MMU would then map the
  25. > virtual into real as the libs are used. Problems would arise if the libs
  26. > have data sections that have to be mapped to different physical
  27. > addresses for different tasks. I have always assumed the libs use stack
  28. > and heap space from the calling task but perhaps this is a bad
  29. > assumption. 
  30.  
  31. On fopen'ing, both tasks believe that the third entry is free.  You
  32. use that entry.  One task writes address 0x9a40 into it, the other
  33. writes 0x9a20.  Immediately, one task has the wrong data available to
  34. it.
  35.  
  36. Malloc() does extend the BSS segment on the binary, extending it towards
  37. the shared library.
  38.  
  39. > You would have to allocate the virtual address space out of a system
  40. > pool on task loading, but you could still map to one physical page as
  41. > long as it was write protected.
  42.  
  43. I will quote from the StrongARM data sheet:
  44.  
  45.  The Dcache operates with virtual addresses, so care must be taken to
  46.  ensure that its contents remain consistent with the virtual to physical
  47.  mappings performed by the memory management unit.  If the memory mappings
  48.  are changed, the Dcache validity must be ensured.
  49.  
  50. On a task switch, the virtual to physical address mappings are changed
  51. to map in the new tasks text segment into 0x8000, so whatever you do with
  52. libraries or anything (unless you're only running multiple copies of the
  53. same program) you HAVE to flush the cache.  You can't get away from it!
  54. No way out!
  55.  
  56. > I see code being sharable, data non sharable, and stacks a bit of a
  57. > problem as you can't allocate them in the middle of nowhere, you have to
  58. > get some virtual space from the operating system when the task is
  59. > created, and the operating system has to be given some hint about the
  60. > stack size required. To make this work ELF would have to tell me what is
  61. > read only and what is read/write. Further linux would have to keep this
  62. > info for the fork, but I think this is the case.
  63. > 
  64. > I have assumed that ZERO_PAGE is write and read protected so you can
  65. > allocate real memory if you actually access it. If this is the case
  66. > would PAGE_ZERO ever get read or written to be cached. Does ZERO_PAGE
  67. > really have to be mapped to real memory.
  68.  
  69. Are you really sure that you want to use Linux for this?  It sounds like
  70. you're basically going to have to re-write the whole of the memory
  71. management system (and therefore the mmap()ing of the filesystems)!
  72.    _____
  73.   |_____| ------------------------------------------------- ---+---+-
  74.   |   |       Russell King      rmk92@ecs.soton.ac.uk         --- ---
  75.   | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  76.   | +-+-+                                                     --- -+-
  77.   /   |               THE developer of ARM Linux              |+| /|\
  78.  /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
  79.     +-+-+ -------------------------------------------------  /\\\  |
  80.  
  81.